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METHOD OF AND SYSTEM FOR DETERMINING 
CONNECTIONS BETWEEN PARTIES USING PRIVATE LINKS 



5 Field of the Invention 

[0001] The present invention relates generally to a method of and 

system for determining connections between parties and, more particularly, to 
a connection searching method and system in which a user is capable of 
entering a source party and a target party and searching a host database to 
10 obtain lists of people or entities through which the source and target parties are 
connected. The system also is capable of determining a number of 
connections that are associated with one party. 

Background of the Invention 

15 [0002] It is well known that personal contacts are advantageous when 

conducting transactions between parties. However, determining the contacts 
of one party of a transaction the contacts of the other party of the transaction 
and what contacts those contacts have in common can be very difficult and 
time consuming. Currently, there is no efficient method or system for 

20 determining such contacts between parties of a transaction. 

Summary of the Invention 

[0003] The present invention is directed to a method of and system for 

determining connections between people which is efficient and effective. The 

25 system includes a host database which includes records of parties, including 
identification information, which is available from non-restricted sources. The 
identification information is arranged in a series of searchable data fields. A 
user connects to a website associated with the system and inputs a source party 
and a target party, for the purpose of finding a number of connections between 

30 the parties. The parties may be people or entities, such as companies, 
organizations, etc. 
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[0004] The system searches the database for intermediate party records 

having at least one data field which includes identification information which 
is common to the identification information in at least one of the data fields of 
the source party record. The located party records are compared to the target 
5 party record to determine if any of the identification information in the 
intermediate party record is common to any of the identification information 
in the target party record. If there is a commonality, a list of the source party, 
intermediate party and target party is generated, including the records for each 
party, to show the connection path between the source party and the target 
10 party. If there are no commonalities between the intermediate party and the 
target party, further intermediate parties are located which have commonalities 
with the first intermediate party. 

[0005] The located party records are then compared to the target party 

record to determine if any of the identification information in the further 

1 5 intermediate part records are common to any of the identification information 
in the target party record. If there is a commonality, a list of the source party, 
intermediate parties and target party is generated, including the records for 
each party, to show the connection path between the source party and the 
target party. This process is repeated until no further connections are found or 

20 until a preset limit of connections is reached. 

[0006] According to one aspect of the invention, a method of 

determining a connection between a source party and a target party includes: 

A. constructing a host database, the host database including a plurality 
of records, each record including a number of data fields, each of the data 

25 fields including identification information of a party, the identification 
information being extracted from non-restricted sources; 

B. constructing a client database, the client database including a 
plurality of records, each record including a number of data fields, each of the 
data fields including identification information of a party, the identification 

30 information being extracted from a client's private sources; 

C. receiving identification information of a source party and a target 

party; 

2 
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D. identifying a record in the client database including identification 
information of the source party; 

E. identifying a record in the host database including identification 
information of the target party; 

5 F. searching the data fields in the records of at least one of the client 

database and the host database to locate identification information 
commonalities between the source party record and at least one intermediate 
party record; 

G. searching the data fields in the records of at least one of the client 
10 database and the host database to locate identification information 

commonalities between the at least one intermediate party record and the 
target party record; and 

H. upon locating at least one identification information commonality 
between the at least one intermediate party record and the target party record, 

15 generating a list including the at least one intermediate party record. 

[0007] Step G may further include searching the data fields in the 

records of at least one of the client database and the host database to locate 
identification information commonalities between the at least one intermediate 
party records and further intermediate party records; and searching the data 

20 fields in the records of at least one of the client database and the host database 
to locate identification information commonalities between the further 
intermediate party records and the target party record. The source party and 
the target party may be one of a person and an entity. The identification 
information may include personal and affiliation information of the party. 

25 [0008] The identification information may include at least one of a 

person's name, the person's dates of employment with a company, the person's 
title within the company, the person's company name, the person's company 
address, the person's company SIC code, and the person's company ticker 
symbol. The identification information may include at least one of a company 

30 name, the company's address, the company's SIC code and the company's 
ticker symbol. The records stored on the client database may be a subset of 
the records stored on the host database. 
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[0009] According to another aspect of the invention, a method of 

determining a connection between a source party and a target party includes: 

A. constructing a host database, the host database including a plurality 
of records, each record including a number of data fields, each of the data 

5 fields including identification information of a party, the identification 
information being extracted from non-restricted sources; 

B. receiving identification information of a source party and a target 

party; 

C. identifying a record in the host database including identification 
10 information of the source party; 

D. identifying a record in the host database including identification 
information of the target party; 

E. searching the data fields in the records of the host database to locate 
identification information commonalities between the source party record and 

15 at least one intermediate party record; 

F. searching the data fields in the records of the host database to locate 
identification information commonalities between the at least one intermediate 
party record and the target party record; and 

G. upon locating a data field commonality between the at least one 
20 intermediate party record and the target party record, generating a list of the at 

least one intermediate party record. 

[0010] According to another aspect of the invention, a system for 

determining a connection between a source party and a target party includes a 
host system having a computer processor and associated memory. The host 
25 system includes a host database including a plurality of records, each record 
including a number of data fields, each of the data fields including 
identification information of a party, the identification information being 
extracted from non-restricted sources. 

[0011] The system also includes a client system having a computer 

30 processor and associated memory, the client system including a client database 
including a plurality of records, each record including a number of data fields, 
each of the fields including identification information of a party, the 
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identification information being extracted from a client's private sources. The 
client system establishes a connection to the host system over the 
communication network and inputs identification information of a source 
party and a target party. 
5 [0012] The host system identifies a record in at least on of the client 

database and the host database including identification information of the 
source party and identifying a record in at least one of the client database and 
the host database including identification information of the target party; and 
the host system searching the data fields in the records to locate identification 

10 information commonalities between the source party record and at least one 
intermediate party record and searching the data fields in the records to locate 
identification information commonalities between the at least one intermediate 
party record and the target party record. Upon locating a identification 
information commonality between the at least one intermediate party record 

15 and the target party record, the host system generating a list of the at least one 
intermediate party record. 

[0013] According to yet another aspect of the invention, a system for 

determining a connection between a source party and a target party includes a 
host system including a computer processor and associated memory and a user 

20 system including a computer processor and associated memory. The host 
system includes a database having a plurality of records, each record including 
a number of data fields, each of the data fields including identification 
information of a party, the identification information being extracted from 
non-restricted sources. The user system is adapted for establishing a 

25 connection to the host system over a communication network and inputting 
identification information of a source party and a target party to the host 
system. 

[0014] The host system identifies records in the database including 

identification information of the source party identification information of the 
30 target party and searches the data fields in the records to locate identification 
information commonalities between the source party record and at least one 
intermediate party record and searching the data fields in the records to locate 
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identification information commonalities between the at least one intermediate 
party record and the target party record. Upon locating a identification 
information commonality between the at least one intermediate party record 
and the target party record, the host system generating a list of the at least one 
5 intermediate party record. 

[0015] According to yet another aspect of the invention, a method of 

determining a connection between a source party and a target party includes: 

A. receiving identification information of a source party and a target 

party; 

10 B- identifying a record in the client database including identification 

information of the source party, the client database including a plurality of 
records, each record including a number of data fields, each of the data fields 
including identification information of a party; 

C. identifying a record in the host database including identification 
15 information of the target party, the host database including a plurality of 

records, each record including a number of data fields, each of the data fields 
including identification information of a party; 

D. searching the data fields in the records of at least one of the client 
database and the host database to locate identification information 

20 commonalities between the source party record and at least one intermediate 
party record; 

E. searching the data fields in the records of at least one of the client 
database and the host database to locate identification information 
commonalities between the at least one intermediate party record and the 

25 target party record; and 

F. upon locating at least one identification information commonality 
between the at least one intermediate party record and the target party record, 
generating a list including the at least one intermediate party record. 

[0016] According to yet another aspect of the invention, a method of 

30 determining a connection between a source party and a target party includes: 

A. receiving identification information of a source party and a target 

party; 
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B. identifying a record in the host database including identification 
information of the source party, the host database including a plurality of 
records, each record including a number of data fields, each of the data fields 
including identification information of a party, the identification information 

5 being extracted from non-restricted sources; 

C. identifying a record in the host database including identification 
information of the target party; 

D. searching the data fields in the records of the host database to 
locate identification information commonalities between the source party 

10 record and at least one intermediate party record; 

E. searching the data fields in the records of the host database to locate 
identification information commonalities between the at least one intermediate 
party record and the target party record; and 

F. upon locating a data field commonality between the at least one 
15 intermediate party record and the target party record, generating a list of the at 

least one intermediate party record. 

[0017] According to yet another aspect of the invention, a system for 

determining a connection between a source party and a target party includes a 
host system including a computer processor and associated memory and a user 

20 system including a computer processor and associated memory. The host 
system includes a database having a plurality of records, each record including 
a number of data fields, each of the data fields including identification 
information of a party. The user system is adapted for establishing a 
connection to the host system over a communication network, the user system 

25 inputting identification information of a source party and a target party to the 
host system. 

[0018] The host system identifies records in the database including 

identification information of the source party identification information of the 
target party and searches the data fields in the records to locate identification 
30 information commonalities between the source party record and at least one 
intermediate party record and searching the data fields in the records to locate 
identification information commonalities between the at least one intermediate 
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party record and the target party record. Upon locating a identification 
information commonality between the at least one intermediate party record 
and the target party record, the host system generating a list of the at least one 
intermediate party record. 
5 [0019] The system described above may also include the various 

features and capabilities described below, which enable a client (i.e., a user of 
host system) to generate a list of persons or entities (including groups of 
persons or groups of lists) that can function as a starting point for a 
connections query or request. This functionality can be referred to as 

10 "ClientLink™" (a trademark of Orion's Belt, Inc.) and made integral with or a 
separate module that works in concert with host operation system. A user's 
personal or private list created using ClientLink can be referred to as the user's 
"PrivateLink™" (a trademark of Orion's Belt, Inc.) or "PrivateLink list". For 
purposes of this description we assume that ClientLink is integral with the host 

15 operation system. 

[0020] As a general overview of a host operation system having 

aspects of PrivateLink, when the connections server and DB (or host system) 
receives a query including a PrivateLink list and an endpoint, the host 
operation system generates information representing the connections to the 

20 endpoint for each member of the PrivateLink list, and returns this to the user. 
In other forms, rather than a single endpoint, a list of endpoints could be used 
(i.e., an endpoint list). In such a case, the host operation system generates 
connections between each member in the PrivateLink list and each member in 
the endpoint list, to the extent such connections exist. In yet another form, a 

25 user may enter a single starting point and an endpoint list. In such a case the 
system generates connections from the starting point to each endpoint in the 
endpoint list, to the extent such connections exist. The following text 
describes these features more fully. 

30 Brief Description of the Drawing s 

[0021] The foregoing and other objects of this invention, the various 

features thereof, as well as the invention itself may be more fully understood 

8 
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from the following description when read together with the accompanying 
drawings in which: 

[0022] FIG. 1 is a schematic diagram of a system for determining 

connections between parties in accordance with the present invention; 
5 [0023] FIG. 2 is a flow diagram showing one embodiment of a method 

for determining connections between parties in accordance with the present 
invention; 

[0024] FIG, is a flow diagram showing another embodiment of a 

method for determining connections between parties in accordance with the 
1 0 present invention; 

[0025] FIG. 4 is a detailed schematic diagram of the system for 

determining connections between parties shown in FIG. 1; 

[0026] FIG. 5 is a schematic diagram showing a list of connections 

determined according to the present invention; 
15 [0027] FIG. 6 is a more detailed schematic diagram of records of the 

parties involved in one of the connections shown in FIG. 5; 

[0028] FIG. 7 is a schematic diagram showing identification 

information included in a record of an entity, according to the present 

invention; and 

20 [0029] FIG. 8A-FIG. 21 are various figures showing the ClientLink 

and PrivateLink functionality that can be added to the system of FIG.s 1-7. 

Detailed Description 

[0030] FIG. 1 shows a schematic diagram of a system 10 for 

25 determining connections between parties in accordance with a preferred 

embodiment of the present invention. The system 10 includes host system 12, 

user system 14 and client systems 16a- 16c, all connected to a common 

communications network 18. While three client systems 16a- 16c are shown in 

FIG. 1, it will be understood that as few as one client system may participate 

30 in the study, or many more than three may participate. Three client systems 

are shown in FIG. 1 for the purpose of example only. Preferably, the host 

system 12, user system 14 and client systems 16a-16c are each a personal 

9 
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computer such as an IBM PC or IBM PC compatible system or an APPLE® 
MacINTOSH® system or a more advanced database computer system such as 
an Alpha-based computer system available from Compaq Computer 
Corporation or SPARC® Station computer system available from SUN 
5 Microsystems Corporation, although a main frame computer system can also 
be used. Preferably, the communications network 18 is a TCP/IP-based 
network such as the Internet or an intranet, although almost any well known 
LAN, WAN or VPN technology can be used. 

[0031] In one preferred embodiment of the invention, the user system 

10 14 is an IBM PC compatible system operating an operating system such as the 
Microsoft Windows® operating system, and host system 12 is configured as a 
web server providing access to information such as web pages in HTML 
format via a protocol such as the Hypertext Transport Protocol (http). The 
user system 14 and client systems 16a- 16c include software to allow viewing 
15 of web pages, commonly referred to as a web browser, thus being capable of 
accessing web pages located on host system 12. Alternatively, user system 14 
and client system 16a- 16c can be any wired or wireless device that can be 
connected to a communications network, such as an interactive television 
system, including WEBTV, a personal digital assistant (PDA) or a cellular 
20 telephone. 

[0032] The method of and system for determining connections 

between parties will now be described with reference to FIGs. 2-7. FIG. 4 is a 
schematic block diagram showing a more detailed diagram of the system 10 of 
FIG. 1. As shown in FIG. 4, host system 12 includes a host operation system 

25 and database 102 and a record matching engine 104. As shown in the figure, 
the client systems 16a- 16c are separate entities, each having a firewall, 
represented by dashed line 124. The client systems 16a-16c are located on the 
client side 120 of the firewall 124 and the host system 12 is located on the host 
side 122 of the firewall 124. Each of client systems 16a-16c include a 

30 company database 110 in which contacts of employees and officers of the 
company are stored. Typical contact programs which are used for storing 
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contacts include ACT®, Outlook®, Goldmine®, and Lotus Notes®. Each client 
system also includes an intermediate list 1 12, a client database 1 14 and a client 
interface 1 16. The operation of these components is described in detail below. 
[0033] FIG. 2 is a flow diagram 20 which shows the method of 

5 determining connection between parties. In step 22, the host database is 
constructed. This involves populating the database with information about 
people and entities such as companies, organizations, etc. This information is 
extracted from non-restricted sources including the SEC database, Market 
Guide, IPO.com, company websites, news articles, press releases, etc. The 
10 information about each person or entity is arranged in a parsable record having 
a number of data fields. Identification information of the person or entity is 
input into an appropriate data field. The identification information input into 
the various data fields includes the name of the person or entity, the address of 
the person or entity, the person's position in the company, the person's dates of 
15 employment with companies the person has worked for, the ticker symbol of 
the company, the SIC code of the company, etc. Preferably, the majority of 
the information is obtained through an automated process, such a web crawler, 
that searches the internet, extracts the appropriate data and inserts the data into 
the data fields to construct a record of the person or entity. Information not 
20 accessible to the automated process is input to the system manually. In this 
step, relationships between parties may be identified and links between related 
records established and saved in the database. This enables connections 
between parties to be included in the records of each party. This step may be 
repeated as often as necessary to keep the database updated. 
[0034] Li step 24, the client database 114 is constructed. First, the 

contact data included in the company database 1 10 is exported to the company 
list 112, and irrelevant contacts, such as personal contacts and non-business 
contacts, are eliminated. Redundant contacts are also eliminated. The 
company list 112 is input to record matching engine 104 where it is compared 
to the records included on host operation system and database 102. All 
contacts in the company list 1 12 that are also included in the host database 102 
are stored in the same record form as the host database contacts and these 
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records are saved in client database 1 14. This step may be repeated as often as 
necessary to keep the database updated. Accordingly, the data stored in the 
client database 1 14 is a subset of the data stored in host database 102. Known 
relationships between records in the client database 1 14 can be determined at 
5 this point and links between the related records implemented into the records. 
The information stored in the client database is proprietary to the client and is 
not accessible by outside parties. Contacts in the company list 112 which are 
not already on the host database 102 are not saved in the client database 1 14, 
since these contacts will not lead to further contacts on the host database 102. 

10 [0035] Once the party records have been constructed and stored in the 

client database 114 and the host database 102, the process of determining 
connections between parties (people and/or entities) can be executed. In step 
26, the host operation system 102 receives identification information of the 
source party and the target party, which typically are the names of the person 

15 or entity, from the client interface 116 of the client system 16 through a 
connection with the host system 12 via the internet 18. The record associated 
with source party is then located in the client database 1 14 if it is stored there. 
If it is not, it is located in the host database 102, step 28. The record 
associated with the target party is also located in either the client database 1 14 

20 or the host database 102. In step 30, the records in the client database 1 14 and 
host database 102 are searched by the host operation system to locate 
commonalities between the identification information in the data fields in the 
source party record and identification information in the data fields of the 
records stored in the databases. All intermediate party records which include 

25 commonalities with the source party record are identified as first stage 
intermediate party records. If relationship links between parties within the 
client database have been previously established, these links are used to locate 
the connections between the source party record and the first stage 
intermediate party record. The identification information in the data fields of 

30 the first stage intermediate party records are then compared to the 
identification information in the data fields of the target party record to locate 
first stage intermediate party records having commonalities with the target 
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party record, step 32. If none of the first stage intermediate party records have 
any identification information commonalities with the target party record, step 
34, the records in the databases are searched to locate further stage 
intermediate party records having identification information commonalities 
5 with the first stage intermediate party records, step 36. The identification 
information in the further stage intermediate party records is searched to 
determine if there are any commonalities between any of the data fields in the 
further stage intermediate party records and the target party record, step 32. 
Steps 32 through 36 are repeated until an intermediate party record is located 

10 which has identification information commonalities with the target party 
record. When this occurs, the host operation system 102 generates a list of the 
parties connecting the source party to the target party, step 38, and transmits 
the list to the client interface 116 via the internet 18. If a preset limit, which 
limits the number of unique connections found to a predetermined number, 

15 which may be set by the client when entering the source and target party 
information or by the host operation system, is met, step 40, the process ends. 
If the preset limit is not met, steps 32 through 36 are repeated until the preset 
limit number of unique connections is met. 

[0036] An example connections list is schematically shown in FIG. 5. 

20 In this example, after the host database 102 and the client database 114 have 
been constructed, steps 22 and 24, FIG. 2, identification information for a 
source party 202 and a target party 204 are input to the host operation system 
102 over the internet 18 through client interface 1 16. For simplicity, the entire 
record of each party is not shown in FIG. 5. Only the relevant identification 

25 information for the purposes of this example are shown. Upon receiving the 
identification information, which typically is the name of the people between 
whom a connection is to be determined, the records of the source party and the 
target party are identified in the client and/or host databases, step 28. In this 
example, the source party 202 is for J.F. who is the Chief Technology Officer 

30 of Company A. The target party record 204 is for L.S., the Chief Financial 
Officer of Company F. In step 30, the host database 102 is searched to locate 
intermediate party records having identification information commonalities 
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with the source party record 202. In this case, the record 206 of CO., which 
indicates that CO. has identification information including a relationship with 
Company A as Chief Operating Officer is located. The remaining 
identification information of the record of CO. is searched to determine 
5 whether there is a commonality between any of the identification information 
of CO. and any of the identification information stored in the record of the 
target party, L.S., step 32. There is a commonality, since the record of CO. 
indicates a relationship with Company F as Chief Technology Officer, step 34. 
Accordingly, a list including the source party record of J.F., the intermediate 
10 party record of CO. and the target party record of L.S. is generated and sent to 
the client interface 116, step 38. In the list, all of the identification 
information included data included in the record of each party is available to 
the client. 

[0037] A more detailed view of the source party record 202, the target 

15 party record 204 and the intermediate party record 206 is shown in FIG. 6. As 
shown in the figure, the records 202, 204 and 206 include data fields listing 
identification information such as the name of the person, age, address and 
relationships to entities such as companies, association, etc. In the example, 
the commonality between the source party record 202 and the intermediate 

20 party record 206 found in step 30 is that both J.F. and CO. have a relationship 
with Company A: J.F. as the present CTO and CO. as a former COO. In step 
32, the commonality between the intermediate party record 206 and the target 
party record 204 is located, namely the relationship of both parties with 
Company F. As shown in record 204, L.S. is the present CFO of Company F 

25 and CO. is the present COO of Company F. 

[0038] In FIG. 5, each entity with which the involved parties are 

associated is indicated by a dashed line. Connections between entities are 
referred to as hops. Since no entities other than the entities associated with the 
source party and the target party are needed to make the connection shown by 

30 double-dotted, dashed line 208, this connection is referred to as a "one-hop" 
connection. Other, multiple hop connections between the source party record 
202 and the target party record 204 are shown in FIG. 5. Line 210 shows a 
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"two hop" connection. Using the method described above, it is determined 
that the record of the source party J.F., 202 indicates a relationship between 
Company A and Company D based on the commonality that J.F. is associated 
with both companies. A further search in host database 102 indicates a 

5 relationship between the record 202 of J.F. and the record 212 of M.P., based 
on the commonality that both parties have a relationship with Company D. 
The record 212 of M.P. indicates a relationship with the target record 204 of 
L.S., based on the commonality that both parties have a relationship with 
Company F. Accordingly, since one intermediate entity (Company D) is 

10 included in the connection 210, this connection is referred to as a "two-hop" 
connection. Three-hop connections are shown by dotted line 220 and dotted 
dashed line 222. In this example, if the preset limit of connections is four, in 
step 40, FIG. 2, the process would end. It will be understood that the preset 
limit can be set to any number, although, in order to minimize processing time 

15 and cumbersome connection lists, the limit preferably is set to no more than 
10. 

i 

[0039] While the example described above shows how connections 

between two people are generated, the system also determines connections 
between a person and an entity, such as a company or association; between an 

20 entity and a person; and between two entities. Upon constructing the client 
database 114, a record of the client entity is generated and stored in the client 
database 114. The host database 102, when being constructed, generates 
records of entities found in its search of the non-restricted sources in the same 
manner as the records for people described above. An example entity record 

25 230 is shown in FIG. 7. As shown in the figure, entity record 230 comprises a 
number of data fields including identification information of the entity, 
including the entity name, ticker symbol, address and a list of its executives. 
When an entity is the source party and/or the target party, the same process 
shown in FIG. 2 is carried out, meaning that intermediate records, which may 

30 include records of people or entities, are located which include identification 
information which is common to the source and or target party records. 
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[0040] In an alternative embodiment, the host operation system and 

database 102 and the record matching engine 104 are replicated on the client 
database 114. In this embodiment, all of the operations described above are 
executed on the client system 16, thus allowing all execution to be local to the 

5 client system 16. Furthermore, the system 10 can be utilized to construct a list 
of connection that are associated with a single party. By inputting a single 
party to the host operation system and database 102, the searching function 
described above is executed and, in a first iteration, all records including 
identification information having commonalities with the source party are 

10 located and displayed. Depending on the scope of connections desired, 
numerous iterations of the search function can be executed in order to locate 
records of parties connected to the parties located in previous iterations. 
[0041] While, as described above, the system 10 may be utilized by 

clients having a proprietary client database, it can also be utilized by a party 

15 which does not construct its own database. This process is shown in the flow 
diagram 240 of FIG. 3. In step 250, the user system 14, FIGs. 1 and 4, 
establishes a connection over the internet to the host system 12. The user 
system then enters the source party and the target party, step 252. The host 
operation system 102 identifies the records associated with the source party 

20 and the target party in the host database, step 254. Once the source party 
record and the target party record are found, steps 256 through 266 are 
executed, which are identical to steps 30 through 40 shown in flow diagram 20 
of FIG. 2. 

[0042] Accordingly, the present invention enables connections 

25 between people and entities to be determined using a convenient and efficient 
database construction and search tool. The invention is able to provide 
information about connections between parties based on commonalities in the 
identification information associated with each of the people and entities. The 
system can also be used simply for browsing through connections between 
30 parties and for obtaining the identification information associated with the 
record for a particular party. While the application has been described in 
connection with an example using businesses and business people as the 
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parties, it will be understood that any party could utilize the connection- 
determining feature of the present invention and be the subject matter, 
including schools, civic groups, churches, organizations, associations, 
families, agencies, neighborhoods, etc., and the people who populate such 
5 groups. 

Client Link and Private Link 

[0043] The system described above may also include the various 

features and capabilities described below, which enable a client (i.e., a user of 
host system 12) to generate a list of persons or entities (including groups of 

10 persons or groups of lists) that can function as a starting point for a 
connections query or request. This functionality can be referred to as 
"ClientLink™" (a trademark of Orion's Belt, Inc.) and made integral with or a 
separate module that works in concert with host operation system 102. A 
user's personal or private list created using ClientLink can be referred to as the 

15 user's "PrivateLink™" (a trademark of Orion's Belt, Inc.) or "PrivateLink 
list". For purposes of this description we assume that ClientLink is integral 
with the host operation system 102 of FIG. 1 . 

[0044] As a general overview of a host operation system 102 having 

aspects of PrivateLink, when the connections server and DB (or host system 

20 12) receives a query including a PrivateLink list and an endpoint, the host 
operation system 102 generates information representing the connections to 
the endpoint for each member of the PrivateLink list, and returns this to the 
user. In other forms, rather than a single endpoint, a list of endpoints could be 
used (i.e., an endpoint list). In such a case, the host operation system 102 

25 generates connections between each member in the PrivateLink list and each 
member in the endpoint list, to the extent such connections exist. In yet 
another form, a user may enter a single starting point and an endpoint list. In 
such a case the system generates connections from the starting point to each 
endpoint in the endpoint list, to the extent such connections exist. The 

30 following text describes these features more fully. 

[0045] In this embodiment, host operation system 102 comprises 

several components: 
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A. host operation system database - which comprises information 
derived from public-domain sources about people and entities 
with which they are associated (current and past) 

B. host operation system application - which comprises software 
5 to extract and parse relevant content from a variety of sources, 

coupled with connection algorithms to search for and identify 
linkages between people and/or entities, and 

C. ClientLink - which provides a secure mechanism for clients to 
link their confidential contact information with host operation 

10 system 102 (or host system 12). 

[0046] The host operation system 102 including ClientLink includes a 

function called Connect that allows clients (or users) to specify both the 
desired endpoints of a connection - people, entities or PrivateLink list - and 
the degrees of separation. It may also provide for an enhanced graphical 

15 display and allow filtering according to the presence of specific people or 
entities in the connection paths (e.g., only show links with Michael Jordan in 
the path). 

[0047] Other optional features include functions to: 

A. develop metrics to rank connections according to their probable 
20 value, 

B. permit the user to assign a personal weighting factor to 
connections, and 

C. display connections in priority order. 

[0048] ClientLink allows clients to integrate knowledge about their 

25 own connections and networks of relationships with the host database 102. 
For a multi-user subscriber, ClientLink can incorporate sophisticated 
permission protocols for controlling access to information by individual users. 
Users can indicate the existing people and entities in the host database 102 
with which they have relationships. Additionally, the host operation system 
30 102 can enable users to "fill in the blanks" with ClientLink, i.e., add additional 
information about relationships between people and entities. All of the 



18 



WO 2005/003917 



PCTYUS2004/020805 



ClientLink information is preferably kept proprietary to the specific 
subscriber. 

[0049] Browse is a function that displays first-order relationships for a 

specified person, entity or PrivateLink list. An optional feature, "Explore", 
5 allows the user to easily determine concentric, expanding relationships 
radiating out from a central ending point, whether a person or an entity. 
Extended Browse capabilities allow searching along a number of parameters 
such as functional position (e.g., CEO) or education (e.g., MIT alumni). 
[0050] ClientLink Integration 

10 [0051] Synchronizing each customer's PrivateLink list or data with 

host operation system 102 is the process whereby names in a user's contact list 
are matched to names in host operation and system database 102. Then, client 
subscribers can connect from their personal or corporate contacts to the 
decision-makers in host database 102. 

15 [0052] The host operation system 102 can accommodate this 

synchronization through a variety of mechanisms, including by using plug-ins 
for popular Customer Relations Management (CRM) and contact management 
systems to customized extraction. 
[0053] ClientLink 

20 [0054] As mentioned above, ClientLink is the feature that links a 

client's own contacts (e.g., customers, referral sources, vendors, etc.) 850 with 
the host database 102 (or connections) in order to produce the most effective 
links for each client. This feature allows a user to specify in a database 856, in 
advance, the people 852 or entities 854 in the host database 102 which are to 

25 be used as sources for a connection, thus eliminating the need to specify a 
unique starting point for each connection request. 

[0055] An individual user's list 860 can be part of a group, and 

connections can be requested using groups as a starting point. This feature 
allows client users to request connections from their own or from their 
30 colleagues' contacts, depending on the flexibility of each client's protocols 
regarding access to lists. In the host operation system 102, a user's ClientLink 
list is called a PrivateLink list. Client administrators have wide latitude in 



WO 2005/003917 



PCTVUS2004/020805 



setting up groups, so that connections can be requested from an office, a 
region, a practice, or an entire organization. Security protocols prevent any 
client from accessing another client's ClientLink data. 

[0056] ClientLink can be customized for each client, e.g., during its 

5 installation. This includes, for example, determining the most effective way to 
make existing contact lists (e.g., from common contact management or CRM 
products) accessible by the host operation system 102, identifying client 
protocols regarding users* lists, and working with the client administrator to 
establish the group/list structure. 
10 [0057] Users can populate their PrivateLink list, e.g., at the time of 

installation, by extracting data from their current contact lists, or they can 
manually enter data into their PrivateLink list as they use host operation 
system 102. 

[0058] Technology 
15 [0059] One embodiment of the technology in ClientLink includes two 

overall components, as discussed in detail above: 

A. Data-collection - integrate data from multiple sources, verify, 
and load into the host operation system and database 102 

B. Connection-finding - search for links between people or entities 
20 and graphically display the results 

[0060] Its components are linked in an overall information architecture 

800, shown schematically in FIG. 8A. 
[0061] Data-Collection Technology 

[0062] The host database 102 contains information about entities, 

25 people, and the relationships among them: 

A. Entities - companies and other organizations (e.g., "IBM") 

B. People - individuals (e.g., "Louis V. Gerstner, Jr.") 

C. Relationships - an affiliation and associated time period (e.g., 
"CEO from 1993") 

30 [0063] This information is derived from publicly available sources 802 

(offered either free or by subscription) by a combination of automated 
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methods with minimal manual intervention. The host database 102 is 
populated via a four-step process: 

1. a web crawler 804 downloads information from public 
web sites 802 or SEC filings 806, identifying 

5 information in headings and tables; 

2. a proprietary parser 812 (discussed below) analyzes the 
data and assembles information about entities, people, 
relationships, and dates; 

3. a data loader transfers this information into the host 
10 database 102; and 

4. continuing updates keep the database current. 
[0064] Web crawlers 

[0065] Web crawlers 804 are generally known in that art, and are used 

here to find and collect data about entities and the individuals associated with 

15 them. This data can be found at company web sites, SEC filings, executive 
biographies 808, structured person-entity relationship data sources 810, and a 
variety of other sources, such as press releases. This data gathering process 
uses a combination of readily available tools (e.g., Wget) and ad-hoc host 
operation system software. The Web crawler can identify some kinds of data 

20 relevant to host operation system 102 by its relationship to headings and tables 
on the HTML page. 
[0066] Parser 

[0067] For public corporations, the most useful sources of 

information— such as SEC filings 806 or company web sites - generally 

25 contain "Executive Biographies" 808, biographical paragraphs that provide 
background and supplementary data about each person associated with a 
particular corporation. These paragraphs are analyzed by a collection of 
computer programs called the "parser" 812 to identify entities, people, and 
relationships among them. An example of a paragraph from an SEC filing for 

30 the TALX Corporation is shown below: 

"Mr. Canfield has been President and Chief 
Executive Officer and a director of the Company 

21 
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since 1986 and has been Chairman of the Board of 
Directors since 1988. He had earlier become 
Chairman of the Board of EKI, Incorporated 
("EKI"), which was acquired by the Company in 
fiscal 1994. For approximately 10 years, Mr. 
Canfield was President of Intech Group Inc. 
("Intech Group"), until its acquisition by the 
Company in 1996, and from 1985 through 1989, 
Mr. Canfield was Chairman, and a principal 
shareholder of Noetic Technologies Corp., an 
engineering software company which was 
purchased by MacNeal-Schwendler Corporation in 
1989. Prior to that, Mr. Canfield was one of two 
founders of Financial Data Systems, Inc. which was 
started in 1968. In 1980, the company, which 
provided services and turnkey systems to savings 
banks, was purchased by Citicorp. Mr. Canfield is a 
director of Jefferson Savings Bancorp, Inc. Mr. 
Canfield holds a Bachelor of Science degree in 
Electrical Engineering from Purdue University and 
an M.B.A. degree from Washington University." 

[0068] First, the parser 812 partitions the paragraph into separate 

sentences. Then, the parser 812 identifies entity names, people names, 
positions, and dates using a set of recognizer programs. Some of these 
25 elements are recognized heuristically (e.g., dates) while others are recognized 
by a combination of heuristics and by looking them up in a pre-defined list 
(e.g., entity names). The parser 812 can have a list of more than 64,000 entity 
names, entity name variants, and aliases (e.g., GE for General Electric 
Corporation). 

30 [0069] Finally, the parser 812 matches sentences containing 

recognized elements against a list of content patterns. If it finds a match, it 
uses the entity and position or title specified in the sentence to generate a 
corresponding relationship between an entity and a person. This relationship 
may also have start and end dates, if these were present in the sentence. If the 

35 parser 812 cannot find a match between a sentence and its list of patterns, it 
creates a candidate pattern based on the sentence structure, but does not create 
a relationship. Instead, it records both sentence and candidate pattern to a log 
file for human review and, where appropriate, for manual input. 



10 



15 



20 



22 



WO 2005/003917 



PCT/US2004/020805 



[0070] The parser 812 used in this embodiment can analyze about 90 

sentences per second and takes about two hours to process all public 
companies listed on the NYSE, NASDAQ and AMEX exchanges. Currently, 
the parser 812 accepts about 30% to 40% of the information it encounters in 
5 free-text format. The acceptance rate will rise as the number of content 
patterns is increased, but it is unlikely to ever reach 100% with the 
techonology presently available; perhaps 60% to 75% is a realistic goal for 
well-written biographical paragraphs. The accuracy of the parsed data is very 
high - around 95%. Because of the high specificity of the parser 812, it will be 
10 able to identify and extract correct relationships when they are mentioned in 
bodies of text where much of the content is on another topic (e.g., from press 
releases). 

[0071] Some sources of data may be of such syntactic complexity or 

poor grammatical quality that the acceptance rate may be much lower. Even 

15 for well- written sources, however, eventually it could reach a point of 
diminishing returns, where the effort required to analyze sentences 
programmatically will exceed the effort required to do so manually. But 
improvements in processing technology could result in significant increases 
the acceptance rate. However, where there are remaining sentences, they can 

20 be analyzed manually. Experience to-date suggests that larger, public 
companies tend to have better-written biographical paragraphs. These 
companies were the first priority for loading into the host database 102. 
[0072] Data Load 

[0073] When the parser 812 has completed its work, the resulting 

25 output undergoes a modest amount of mostly automated follow-up processing 
to: 

1. identify and merge records to match up multiple 
references to a specific person from different sources by 
the same or closely related names; 
30 2. identify and merge overlapping positions (different 

source paragraphs may refer to the same position with 
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slightly different dates or with a different wording of 
the title); and 
3. perform a sanity check on the parser output. 
[0074] The results from parser 812 and any structured person-entity- 

5 relationship data 810 are passed to an assembly and merge database 814, 
which bring the data together, along with any data from licensed data sources 
816 and any "data curator tools" 818 provided for accessing data stored within 
the system or other known repositories. The assembly and merge database 
ultimately provides a production database 820, which is the host database 102. 
10 [0075] As host database 102, database 820 is used by the ClientLink 

functionality 822 and web site and connect functionality of host operation 
system 102. The ClientLink functionality 822 can use client (or customer) 
contact and CRM data, input by the customer 830 to help build the production 
database 820. 

15 [0076] Database 830 (i.e., host database 102) can be generated using 

computer software to extract information from electronically available data 
sources, as discussed. Human input can also be used, if needed, to: 

1 . identify trustworthy information sources; 

2. construct and correct errors in the parsing program 
20 results and their associated data tables, if any, and 

3. review the entity-name list (which is used by the parser 
812 to recognize valid entity names). 

[0077] Update process 

[0078] The host database 102 can be kept current in several ways: 

25 1. make corrections and data updates as learned (e.g., from 

press releases, company web sites, etc); 
2. the parsing technology can also compare current data 
(from our existing sources) against the database 102 - if 
an entity/person/relationship set is in database 102, but 
3° no longer in the source, an end date is inserted for that 

relationship, or if entities, persons, or relationships are 
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found in our sources, but not in the database, they are 
added to the database; and 
3. statistical sampling can be used to verify the accuracy 
of the information loaded into database 102. 
5 [0079] Database updates are preferably done daily, and only allowed 

from a single system with a secure connection to the database 102. All 
database changes (corrections, additions, and deletions) can be logged to 
create an audit trail. 

[0080] Connection-finding technology 

10 [0081] The connection-related technology includes a user interface for 

access to the host database 102, and the algorithms required to find and to 
display connections between people and entities as requested by a user. 
[0082] Access to Host Operation System 

[0083] Users access the host operation system 102 via a graphical, 

15 browser-based interface by customer 130 (e.g., user 14 from FIG. 1). User 
requests are transmitted to a web server and thence to an application server, 
where database queries are converted to SQL and forwarded to an Oracle 
database engine, in the present embodiment. 

[0084] Referring to FIG. 8A, there are three key features available for 

20 users, as follows: 

1. Connections 824 

2. ClientLink 822 

3 . Browse (by Customer 830) 
[0085] Connections 

25 [0086] Users can ask the host operation system 102 (i.e., DB 820) to 

find connecting paths between a starting point (either a person or an entity) 
and an end point (which can also be either a person or an entity). Hence there 
are four connection possibilities: 

1. Person to Person 

30 2. Person to Entity 

3. Entity to Person 

4. Entity to Entity 

25 
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[0087] For example, suppose a user wanted to know if there was a path 

between John Phelan (a former chairman of the New York Stock Exchange) 
and Exxon Mobil Company. After requesting a Person-to-Entity connection, 
the user is asked to specify the person and the entity, as shown in the screen 
5 shot 900 of FIG. 9. Here, the user enters the name of the person, in fields 910 
and the name of the entity in field 920. The degrees options 930 specify the 
number of people allowed between the starting and ending points. Choosing 
"Connect" button 940 causes the host operation system to generate the 
requested list. 

10 [0088] FIG. 10 is a screen shot 1000 that allows the user to uniquely 

identify the desired person and entity from among several possible candidates 
in a list 1010 generated when the user selected the Connect button 940 from 
FIG. 9. That is, the user input "Phelan"s as the last name for the person (end 
point) in FIG. 9. FIG. 10 shows, in list 1010, that the system included several 

15 Phalens in the database. Additionally, list 1020 shows that there were several 
"Exxon"s in the database. The user can choose one or more from each list 
1010, 1020. 

[0089] After selecting the particular one or more person and entity 

desired in FIG. 10, the system searches for possible paths between these 

20 starting and ending points, and displays a summary page, shown in the screen 
shot 1 100 of FIG. 1 1. The summary screen 1 100 shows the starting point (or 
connect from point) 1110 and the ending point (or connect to point) 1120. 
Screen 1100 also shows the number of degrees 1130, as well. Screen 1100 
includes summary table 1140, which is shown with three columns: Degree, 

25 Number of Connection and View. The view column includes check boxes to 
allow the user to select records from the table to view. Summary table 1 140 
shows that there were 2 connections with 1 degree (or hop) and 8 connections 
having 2 degrees (or hops). 

[0090] Screen 1100 also includes three buttons 1150: View Table, 

30 View Graphic, and Filter Results. The Filter Results button allows the user to 
filter the results, which is valuable when a large number of connections are 
returned. The View Graphic button generates a screen that depicts the 
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connections graphically, as demonstrated in FIG. 15, as an example. Selection 
of View Table generates screen shot 1200 of FIG. 12. At the top of the screen 
1200, a person and entity identifications 1210 are provided. The results have 
been listed beginning with all 1 degree connections 1220, then 2 degree 
5 connections 1230 - presuming that the 1 degree connections may be, at least 
in initially, of the highest interest. Each connection is identified by a sub- 
table, where each row is a record for a person or entity. For example, sub- 
table 1222 shows John J. Phelan, Jr. being associated with Metropolitan Life 
Insurance Company, which is in turn associated with Helen L. Kaplan. In the 
10 second row of sub-table 1222, Helen L. Kaplan is associated with Exxon 
Mobile Corporation. As a result, John J. Phelan, Jr. as a link to Exxon Mobile 
Corporation. 

[009 1 ] Within the host operation system 1 02, a user's ClientLink list is 

called a PrivateLink. Users can request connections from their PrivateLink to 

15 either a person or an entity. An example is shown in the screen shot 1300 of 
FIG. 13, requesting a connection from a JSM's PrivateLink list (or "JSM's 
List 1310) to Michael Dell of Dell Computer Corporation. JSM's List is 
shown belonging to a group in field 1320, called "Orion's Belt". Together, 
fields 1310 and 1320 define the "Connect From" entry. To define the 

20 "Connect To" entry, there is provided input boxes 1330, into which the name 
Michael Dell has been entered. As before, a set of degrees boxes 1340 is 
provided to allow the user to set limits on the search as a function of the 
number or intermediate connections (or hops) between the "to" and "from" 
points. 

25 [0092] Selection of the Connect button 1350 of FIG. 13 causes the 

system to generate the screen shot 1400 of FIG. 14. Screen shot 1400 is a 
summary display that shows the "owners" of the lists that have connections. 
The user can avail themselves of both their own and their colleagues' 
connections to maximize the likelihood of finding a reasonable link to a 

30 designated destination. A user's ability to access PrivateLink lists other than 
his or her own is determined by the client administrator. This particular 
example shows how a number of people in the selected group (see FIG. 13) 
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can make use of their colleagues' lists to find the best path to the desired end- 
point (here Michael Dell). In these tables, the name of the list (or List Name) 
is provided in the first column and the name of the List Owner is provided in 
the second column. The #Results column shows the number of lists with 
5 connections to the end point. If there is a "0" result, there is no opportunity to 
select View in the final column. As shown in sub-table 1410, JSM's List for 
1 degree produced no results, but in sub-table 1420 for 2 degrees, JSM's List 
produced 4 results. 

[0093] In sub-table 1410, JLD's List and MMacksoud's List each had 

10 1 result. These were each selected for viewing in the View column. This 
time, selection of the View Graphic button 1430 produces screen shot 1500 of 
FIG. 15. Screen shot 1500 displays the connections from within each list, 
shown using the graphical view. Here, graphic 1510 shows the result for 
JLD's List from sub-table 1410 of FIG. 14 and graphic 1520 shows the results 

15 from MMachsoud's List. Viewing graphic 1510, Janet Duchaine, the owned 
of JLD's List, connects to Micheal S. Dell view Rochelle B Lazarus (of 
General Electric Company), which has a connection via Samuel A. Nunn, Jr. 
(of Dell Computer Company) to Michael S. Dell. 
[0094] Connection Technology Extensions 

20 [0095] Beyond that described above, extensions to the connection 

technology could be selectively implemented. The connection algorithms look 
for overlaps between the time periods during which two or more people were 
associated with an entity. But the connection algorithms themselves have no 
intrinsic knowledge of people and entities - they actually look for overlaps 

25 between entries in a general-purpose relational database. These entries could 
be, for example: 

1 . Web sites and their visitors 

2. Trucks and their cargo 

3. Airline flights and their passengers 

30 [0096] More generally, entries in the database can represent containers 

or contents-of-containers, where a content entry is associated with a container 
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entry over some (perhaps indefinite) period of time. Containers can 
themselves be the contents of other containers. 

[0097] The connection technology and associated user interface can 

also be applied to clients' private databases (e.g., a recruiting firm's inventory 
5 of potential candidates). Third-party databases can be integrated into the 
service providing the host operation system, permitting revenue sharing 
arrangements with established content providers. 
[0098] Browse 

[0099] The browse function (shown has a selectable function in FIG.s 

10 9-15, enables a user either to look at people, and the entities with which they 

are associated, or to look at entities, and the people associated with them. The 

browse function can be invoked at any time during the connection process; 

there is also a separate browse function on the main menu. The browse 

function can be extended to include an "explore" function, which begins with 
15 the endpoint (person or entity) and display progressively larger circles of 

contacts, so that the user might look for known contacts. 

[00100] ClientLink 

[00101] ClientLink may also be further appreciated with respect to 
FIG.s 16-21. FIG. 16 is a top level diagram depicting a PrivateLink 

20 implementation, wherein a user's PrivateLink list 1610 can be resident on the 
connections system, user system, third party system, or some combination 
thereof. FIG. 16 shows that in either database, a list can include individuals, 
entities, or groups, or combinations thereof. FIG. 17 is a diagram that shows 
that when a user sends a target endpoint and PrivateLink, the system 102 

25 returns connections for members of PrivateLink, to end point, which 
corresponds to FIG. 16. 

[00102] FIG. 18 is a diagram 1800 that shows a PrivateLink list 1804 
with an endpoint (or target) list 1802, rather than giving a single endpoint. A 
user's PrivateLink list 1804 and endpoint list 1802 can be resident on the 
30 connections system 102, user system, third party system, or some combination 
thereof. FIG. 19 is a diagram 1900 that shows a query and results process 
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when using a PrivateLink list with endpoint list, which corresponds to FIG. 
18. 

[00103] FIG. 20 is a diagram 2000 that shows only the use of an 
endpoint list 2004. A user's endpoint list 2004 can be resident on the 
5 connections system, user system, third party system, or some combination 
thereof. FIG. 21 is a diagram 2100 that shows the query and results process 
using the endpoint list 2004 of FIG. 20. 

[00104] The invention may be embodied in other specific forms without 
departing from the spirit or essential characteristics thereof. The present 

10 embodiments are therefore to be considered in respects as illustrative and not 
restrictive, the scope of the invention being indicated by the appended claims 
rather than by the foregoing description, and all changes which come within 
the meaning and range of the equivalency of the claims are therefore intended 
to be embraced therein. As used herein, the terms "includes" and "including" 

15 mean without limitation. It is intended by the following claims to claim any 
and all modifications and variations that fall within the true scope of the 
inventive concepts. 
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